pp108 : Leveraging XQY Extensions in WS-AppServer

Leveraging XQY Extensions in WS-AppServer

This topic describes the XQY extensions that are used by WS-AppServer in storing data in the databases.


WS-AppServer uses the XQY layer for database persistence. XQY has certain extensions that provide specific functionality to WS-AppServer. This topic describes the options (attributes) that WS-AppServer provides to leverage these extensions. These options can be set both at method implementation stage and in the SOAP requests.
Following are the options provided by WS-AppServer.

Option

Applicable Values

Default Value

Operations

Database Providers

Database(s)

reply

  • Yes
  • No

Yes

  • Insert 
  • Update
  • Delete
  • OLEDB
  • JDBC

All databases

preserveSpace

  • True
  • False

False

  • Insert
  • Update
  • Delete
  • Query
  • OLEDB
  • JDBC

All databases

commandUpdate

  • Yes
  • No

No

  • Insert
  • Update
  • Delete

OLEDB

All databases

batchUpdate

  • Yes
  • No

No

  • Insert
  • Update
  • Delete
  • OLEDB
  • JDBC

All databases

 

Using 'reply'

This attribute is used to re-read the database for a given operation and send the response.

For an insert request with reply='yes', XQY fires a select query with the given primary key, reads the database after the insert operation, and sends the response back.

If this attribute is set to 'no' (reply='no'), then XQY skips reading the database after the insert operation (thereby improving performance) and WS-AppServer sends an empty response. Setting this attribute to 'no' helps in cases where there are bulk inserts or updates, and you may not want to retrieve the inserted row information for every request.

The default value is 'yes'. You may set the attribute to 'no' in one of the following ways:

  • In a SOAP request, add an attribute 'reply' with value 'no' (reply='no').
  • In method implementation, add an attribute 'reply' with value 'no' to the update method stored in LDAP.

The examples of using this attribute when WS-AppServer is in SOAP mode, are given below:

Reply

SOAP Request

SOAP Response

Yes

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <UpdateCustomer reply="yes" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"> <tuple> <new> <Customer> <id>1</id> <name>PARAMETER</name> </Customer> </new> </tuple> </UpdateCustomer> </SOAP:Body> </SOAP:Envelope>
<data> <UpdateCustomer reply="yes" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"> <tuple> <new> <Customer> <id>1</id> <name>PARAMETER</name> </Customer> </new> </tuple> </UpdateCustomer> </data>

No

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <UpdateCustomer reply="no" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"> <tuple> <new> <Customer> <id>1</id> <name>PARAMETER</name> </Customer> </new> </tuple> </UpdateCustomer> </SOAP:Body> </SOAP:Envelope>
<data> <UpdateCustomer reply="no" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"/> </data>

The examples of using this attribute when WS-AppServer is in embedded (standalone) mode, are given below:

Reply

Code

Yes

BSF.getObjectManager().setNoReply(false); 

No

BSF.getObjectManager().setNoReply(true); 

Note: JDBC connectors do not support insertion into tables with an auto-generated field as the primary key. In such a case, setting reply='no' enables insertions.

Using 'preserveSpace'

This attribute is used to preserve the trailing white space in the text, while rendering it in the SOAP response. It is used by the XQY layer and applies only to the response. It does not affect the actual information that gets stored in the database. In other words, if the original data has a trailing white space, it is stored in the database intact. Whereas, the response may or may not contain the trailing white space depending upon the attribute setting.
The default value for this attribute is 'false', which truncates the white space at the end of the data (trailing space) in the response. If this attribute is set to 'true', the white space at the end of the data is preserved in the response.
Note: If you are testing this functionality using the Process Platform SOAP Node Test tool, you will observe that when the attribute is set to 'true', irrespective of the number of spaces given in the request, the preserved trailing space in the response is restricted to a 'single' space. This is because the Microsoft XML parser used in Process Platform truncates the additional trailing spaces, even when the value is set to true. On the other hand, if you use any other program to test this functionality, the number of spaces shown in the response tally with the spaces that get stored in the database. You may set the attribute to 'true' in one of the following ways:

  • In a SOAP request, add an attribute 'preserveSpace' with value 'true' (preserveSpace='true').
  • In the method implementation, add an attribute 'preserveSpace' with value 'true'.

The examples of using this attribute when WS-AppServer is in SOAP mode, are given below:

 

If preserveSpace=false

If preserveSpace=true

Insert SOAP Request

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <UpdateCustomer preserveSpace="false" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"> <tuple> <new> <Customer> <id>1</id> <name> abc </name> </Customer> </new> </tuple> </UpdateCustomer> </SOAP:Body> </SOAP:Envelope>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <UpdateCustomer preserveSpace="true" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"> <tuple> <new> <Customer> <id>1</id> <name> abc </name> </Customer> </new> </tuple> </UpdateCustomer> </SOAP:Body> </SOAP:Envelope>

Insert SOAP Response

data> <UpdateCustomer preserveSpace="false" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"> <tuple> <new> <Customer> <id>1</id> <name> abc</name> </Customer> </new> </tuple> </UpdateCustomer> </data>
 <data> <UpdateCustomer preserveSpace="true" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"> <tuple> <new> <Customer> <id>1</id> <name> abc </name> </Customer> </new> </tuple> </UpdateCustomer> </data>

Query SOAP Request

<GetCustomerObject preserveSpace="true" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"> <id>1</id> </GetCustomerObject>

Query SOAP Response

 <data> <GetCustomerObjectResponse preserveSpace="true" xmlns="http://schemas.cordys.com/Ws-AppServer/Testing"> <tuple> <old> <Customer> <id>1</id> <name> abc </name> </Customer> </old> </tuple> </GetCustomerObjectResponse> </data> 

The examples of using this attribute when WS-AppServer is in embedded mode, are given below:

preserveSpace

Code

Yes

BSF.getObjectManager().setPreserveSpace(true); 

No

BSF.getObjectManager().setPreserveSpace(false); 

 

Using 'commandUpdate'


This attribute is used to perform update operations for OLEDB providers that do not support row set-based updates, or for updating fields of type 'LOB' that are NOT NULL.

If this attribute is set to 'yes', XQY uses SQL update command API's to facilitate insert/update/delete operations on each row of the database table. Following the update, it does a re-read and sends the response.

If this attribute is set to 'no', the native implementation (row set-based update) is used to facilitate the insert/update/delete operations.

This attribute is also used in special cases (OLEDB with SQL Server) wheredateTimefields are rounded off, and on executing an update request, the data stored in table does not reflect in the SOAP response. As a workaround, WS-AppServer provides this option to re-read the database record after performing an update.

LIMITATION

WhencommandUpdate='yes', OLEDB does not support insertions to tables with an auto-generated primary key field. In such a case, setreply='no'to enable insertions
The default value is 'no'. You may set the attribute to 'yes' in one of the following ways:

  • In a SOAP request, add an attribute 'commandUpdate' with value 'yes' (commandUpdate='yes')
  • In a method implementation, add an attribute 'commandUpdate' with value 'yes' to the update method stored in LDAP

The examples of using this attribute when WS-AppServer is in SOAP mode, are given below:

commandUpdate

Yes

SOAP Request

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <Update commandUpdate="yes" xmlns="http://schemas.cordys.com/Ws-AppServer/TestPkg"> <tuple> <old> <Employee> <BirthDate>2005-09-11T11:19:08.320000000</BirthDate> <LastName>abc</LastName> <FirstName>pqr</FirstName> <HireDate null="true"/> </Employee> </old> <new> <Employee> <BirthDate>2005-09-11T11:19:08.320000000</BirthDate> <LastName>abc</LastName> <FirstName>xyz</FirstName> <HireDate>2005-09-11T11:19:08.931000000</HireDate> </Employee> </new> </tuple> </Update> </SOAP:Body> </SOAP:Envelope>

SOAP Response

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <UpdateResponse commandUpdate="yes" xmlns="http://schemas.cordys.com/Ws-AppServer/TestPkg"> <tuple> <old> <Employee> <BirthDate>2005-09-11T11:19:08.320000000</BirthDate> <LastName>abc</LastName> <FirstName>pqr</FirstName> <HireDate null="true"/> </Employee> </old> <new> <Employee> <BirthDate>2005-09-11T11:19:08.320000000</BirthDate> <LastName>abc</LastName> <FirstName>xyz</FirstName> <HireDate>2005-09-11T11:19:08.930000000</HireDate> </Employee> </new> </tuple> </UpdateResponse> </SOAP:Body> </SOAP:Envelope>

Note: Consider the original <HireDate> value which is 2005-09-11T11:19:08.931000000. However, as seen in the response, the value that was stored in database after it was rounded off is 2005-09-11T11:19:08.930000000. Without the commandUpdate option, the response would have had <HireDate>2005-09-11T11:19:08.931000000</HireDate>, which is different from the value stored in the database. To use this attribute when WS-AppServer is in embedded mode (standalone), use the following code:

BSF.getObjectManager().setCommandUpdate(true);

Using 'batchUpdate'


Batch update enables users to update same set of columns for multiple records in a database table. Using batch update, you can send multiple updates (insert, update or delete requests) in an single Update request, to be executed as a batch rather than sending these requests separately. This facility helps in improving the performance of WS-AppServer.
To enable batch update, you must set the batchUpdate attribute to 'yes' in the implementation of specific update ( <objectname>update ) Web service operation. The default value is 'no'.
Note: It is not possible to run batch update for generic update Web service operation Update . You may set the attribute to 'yes' in one of the following ways:

  • In the SOAP request, add an attribute 'batchUpdate' with value 'yes' (batchUpdate='yes')
  • In the method implementation, add an attribute 'batchUpdate' with value 'yes', to the update method stored in LDAP

The examples of using this attribute when WS-AppServer is run in SOAP mode, are given below:

batchUpdate

Yes

SOAP Request

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <UpdateCategories batchUpdate="yes" commandUpdate="no" preserveSpace="no" reply="yes" xmlns="http://schemas.cordys.com/db12313"> <tuple> <new> <Categories qAccess="0" qConstraint="0" qInit="0" qValues=""> <CategoryName>ships</CategoryName> <Description>shipDesc</Description> </Categories> </new> </tuple> <tuple> <new> <Categories qAccess="0" qConstraint="0" qInit="0" qValues=""> <CategoryName>Car</CategoryName> <Description>CarDesc</Description> </Categories> </new> </tuple> </UpdateCategories> </SOAP:Body> </SOAP:Envelope>

SOAP Response

<data> <UpdateCategoriesResponse batchUpdate="yes" commandUpdate="no" preserveSpace="no" reply="yes" xmlns="http://schemas.cordys.com/db12313" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <tuple xmlns="http://schemas.cordys.com/db12313" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <new xmlns="http://schemas.cordys.com/db12313" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <Categories xmlns="http://schemas.cordys.com/db12313"> <CategoryName>ships</CategoryName> <Description>shipDesc</Description> </Categories> </new> </tuple> <tuple xmlns="http://schemas.cordys.com/db12313" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <new xmlns="http://schemas.cordys.com/db12313" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <Categories xmlns="http://schemas.cordys.com/db12313"> <CategoryName>Car</CategoryName> <Description>CarDesc</Description> </Categories> </new> </tuple> </UpdateCategoriesResponse> </data>


To use this attribute when WS-AppServer is in embedded mode (standalone), use the following code:

BSF.getObjectManager().setBatchUpdate(true);

Along with batchUpdate, you can also use the attribute batchSize (batchSize="number"). However, this attribute can be used only in the embedded mode or by customizing the Java classes as per the following code:

BSF.getObjectManager().setBatchSize(100);

. For details, refer to the Java API.

Using options in method implementation

Set the options (attributes) in the method implementation, as shown below:

  • To set the option for an update request, use the following code:
    <implementation type="BsfUpdate"> <update commandUpdate="yes|no" reply="yes|no" preserveSpace="true|false" batchUpdate="yes|no"/> </implementation>
  • To set the option for a query request (GetXXXXObjects), use the following code:
    <implementation type="BsfJavaCall" preserveSpace="true"> <class>com.myapp.Customer</class> <method scope="out" dt="java:com.myapp.Customer[]" ct="tuples" wt="true">getCustomerObjects</method> <parameters> <fromId dt="int"/> <toId dt="int"/> </parameters> </implementation>



    Note: The attributes set in SOAP requests take precedence over the method implementation.